
Study on cryptographic protocols 



November, 2014 




* eriisa 

* * 

European Union Agency for Network and Information Security www.enisa.eurooa.eu 




Study on cryptographic protocols 



November, 2014 



About ENISA 



The European Union Agency for Network and Information Security (ENISA) is a centre of network and 
information security expertise for the EU, its member states, the private sector and Europe's citizens. 
ENISA works with these groups to develop advice and recommendations on good practice in 
information security. It assists EU member states in implementing relevant EU legislation and works 
to improve the resilience of Europe's critical information infrastructure and networks. ENISA seeks to 
enhance existing expertise in EU member states by supporting the development of cross-border 
communities committed to improving network and information security throughout the EU. More 
information about ENISA and its work can be found at www.enisa.europa.eu . 

Authors 

This work was commissioned by ENISA under contract ENISA D-COD-14-T09 (under F-COD-13-C23) to 
the consortium formed by K.U.Leuven (BE) and University of Bristol (UK). 

• Contributors: Nigel P. Smart (University of Bristol), Vincent Rijmen (KU Leuven), Martijn Stam 
(University of Bristol), Bogdan Warinschi (University of Bristol), Gaven Watson (University of 
Bristol). 

• Editor: Nigel P. Smart (University of Bristol). 

• ENISA Project Manager: Rodica Tirtea. 

Agreements of Acknowledgements 

We would like to extend our gratitude to: 

• External Reviewers: Michel Abdalla (ENS Paris), Kenneth G. Paterson (Royal Holloway, University 
of London), Ahmad-Reza Sadeghi (T.U. Darmstadt), Michael Ward (Mastercard) for their 
comments suggestions and feedback. 

• We also thank a number of people for providing anonymous input and Cas Cremers (Oxford 
University) and Hugo Krawczyk (IBM) for detailed comments on various aspects. 

Contact 

For contacting the authors please use sta@enisa.europa.eu . 

For media enquires about this paper, please use press@enisa.europa.eu . 



Page ii 




Study on cryptographic protocols 



November, 2014 



Legal notice 



Notice must be taken that this publication represents the views and interpretations of the authors and 
editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the 
ENISA bodies unless adopted pursuant to the Regulation (EU) No 526/2013. This publication does not 
necessarily represent state-of the-art and ENISA may update it from time to time. 

Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external 
sources including external websites referenced in this publication. 

This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA 
nor any person acting on its behalf is responsible for the use that might be made of the information contained 
in this publication. 

Copyright Notice 

© European Union Agency for Network and Information Security (ENISA), 2014 
Reproduction is authorised provided the source is acknowledged. 

Catalogue number TP-06-14-085-EN-N ISBN 978-92-9204-103-8 DOI 10.2824/3739 



Page iii 




Study on cryptographic protocols 



November, 2014 



Executive summary 

Cryptographic algorithms, when used in networks, are used within a cryptographic protocol. In the 
ENISA algorithms report of 2013 [113], several protocols were discussed. In this document (which is 
the sister document of the 2014 report [115]) we extend the work in the 2013 report to cover more 
categories of protocols. 

The focus of this report is on decision makers in corporations and governments making decisions as 
to what protocols to use so as to protect online communications which contain personal data which 
needs to be kept private. Even if the cryptographic primitives and schemes (discussed in [115]) are 
deemed secure, their use within a protocol can result in a vulnerability which exposes the supposedly 
secured data. 

Another focus of the report is to point out the paucity of work, which demonstrates that standard 
protocols meet well defined security goals. Thus the report, hopefully, will act as a stimulus to 
researchers and funders in this area to focus efforts on the important area of cryptographic protocols. 
Whilst the security of basic cryptographic building blocks, such as primitives and protocols, is well 
studied and understood, the same cannot be said of cryptographic protocols. The scientific study of 
such protocols can be said to be still not mature enough. 

As an example of this infancy we point to the discussion in this document on TLS (Transport Layer 
Security) security, Section 3.1. The TLS protocol is the protocol used to secure traffic from web-sites 
to browsers; despite a lot of effort on understanding this protocol in the last few years, basic protocol 
errors are still being found (e.g. Luckyl3 [17]), as well as implementation errors (e.g. HeartBleed [87]). 
In this report we focus on the former type of problems as opposed to the latter type of problems. 

Guidelines 

The following guidelines are addressed to researchers in the field: 

1. Many cryptographic and security protocols have in the past been designed by networking and 
protocols experts, and not by cryptographic protocol experts. The design of cryptographic 
protocols is particularly challenging, and the associated security proofs to guarantee 
correctness are vastly more complicated than those for cryptographic schemes. Researchers 
need to work on simplifying the analysis, and enabling automated tools to provide strong 
computational guarantees using computational soundness results. 

2. More attention needs to be paid to automated verification that an implementation of a 
protocol actually meets a given security goal. This is distinct from showing that an abstract 
protocol meets a given security goal described above. This problem is particularly challenging, 
compared to normal automatic code verification, due to the interactive nature of protocols. 
Thus researchers need to examine how such automated tools can guarantee correct 
implementation of a protocol design. 

3. Designers and implementers should refrain from "optimising" well studied protocols to 
achieve some specific application need; unless they are prepared to revisit and re-evaluate 
the above security proofs. Small insignificant changes in protocols can result in invalidating 
the guarantees of such proofs. 

The key problem with protocols today is that many result from cryptographic design many years (even 
decades) ago. Thus cryptographic protocols suffer more from legacy issues than the underlying 
cryptographic components. The goal should be to work towards a better cryptographic protocol 
infrastructure which does not exhibit such problems. Thus we provide the following guidelines to 
organisations which are developing new protocols: 
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1. Future protocols should be designed using solid and well-established engineering principles, 
but also with ease of formal security analysis in mind, and ideally in conjunction with the 
development of formal security proofs. They should also be designed in the light of the state 
of the art in cryptanalysis of their constituent primitives. The many issues that have arisen in 
real world protocols in recent years highlight the inadequacies of the ad hoc design approach, 
albeit it supported by well-established "rules of thumb" 

2. Future protocols should not be any more complex than they need to be (eliminate extraneous 
options which only invite attacks - e.g. renegotiation attacks, and Triple Handshake attacks on 
TLS; the high number of key exchange options in IPSec). 

3. Carefully designed protocols will exhibit algorithm agility and secure version negotiation to 
support future development (but not at the expense of simplicity). Thus, lock in of 
cryptographic protocols and schemes for many years should be avoided. It should be relatively 
easy to upgrade cryptographic components, by designing protocols in a modular manner. 
Enabling components which are no longer deemed secure to be swapped out. 

4. More work needs to be performed on verifying Application Programming Interfaces (APIs) for 
application protocols. Both in terms of understanding their security properties and verifying 
that the API meets such properties. For example a secure channel API should be secure as long 
as the underlying cryptographic components are secure; no security weakness should be 
introduced by the API itself. 
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Acronyms 



3DES Triple DES 

3GPP 3rd Generation Partnership Project (mobile phone system) 

A5/X Stream ciphers used in mobile phone protocols 

ABE Attribute Based Encryption 

AE Authenticated Encryption 

AEAD Authenticated Encryption with Auxiliary Data 

AES Advanced Encryption Standard 

AESKW A Key Wrap Scheme 

AH Authentication Header 

AKA Authentication and Key Agreement 

AKW1 A Key Wrap Scheme 

AKW2 A Key Wrap Scheme 

AMACANSI Retail MAC 

ANSI American National Standards Institute 

BB Boneh-Boyen (ID based encryption) 

BF Boneh-Franklin (ID based encryption) 

BPP Binary Packet Protocol 

BPR Bellare, Pointcheval and Rogaway 

BMP Boyko, MacKenzie and Patel 

CBC Cipher Block Chaining (mode) 

CCA Chosen Ciphertext Attack 

CCM Counter with CBC-MAC (mode) 

CFB Cipher Feedback 

CMA Chosen Message Attack 

CMAC Cipher-based MAC 

CPA Chosen Plaintext Attack 

CTR Counter (mode) 

CVA Ciphertext Validity Attack 

CWC Carter-Wegman + Counter 

DAA Direct Anonymous Attestation 

DEM Data Encapsulation Mechanism 

DES Data Encryption Standard 

DLP Discrete Logarithm Problem 

DSA Digital Signature Algorithm 

E0 A stream cipher used in Bluetooth 

EAX Actually stands for nothing (mode) 

EC2 Elastic Computing Cloud 

ECB Electronic Code Book (mode) 

ECC Elliptic Curve Cryptography 

ECDLP Elliptic Curve Discrete Logarithm Problem 

ECIES Elliptic Curve Integrated Encryption Scheme 

EEA EPS Encryption Algorithm 

EIA EPS Integrity Algorithm EKE Encrypted Key Exchange 
EMAC Encrypted CBC-MAC 
EME ECB-mask-ECB (mode) 

EMV Europay-Mastercard-Visa (chip-and-pin system) 

ENISA European Union Agency for Network and Information Security 

ESP Encapsulating Security Payload 

FDH Full Domain Hash 

FHE Fully Homomorphic Encryption 

GCM Galois Counter Mode 

GDSA German Digital Signature Algorithm 

GMAC The MAC part of the GCM block cipher mode 

GSM Groupe Special Mobile (mobile phone system) 

HMAC A hash based MAC algorithm 

IAPM Integrity Aware Parallelizable Mode 

IEC International Electrotechnical Commission 

IEEE Institute of Electrical and Electronics Engineers 

IETF Internet Engineering Task Force 

IKE Internet Key Exchange 

IND Indistinguishability of Encryptions 

INT-CTXT Integrity of Ciphertexts 

IPsec Internet Protocol Security 

ISO International Standards Organization 

IV Initialisation Vector (or Value) 

J-PAKE Password Authenticated Key Exchange by Juggling 
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KDSA Korean Digital Signature Algorithm 

KDF Key Derivation Function 

KEM Key Encapsulation Mechanism 

KW AES Key Wrap 

KWP AES Key Wrap with Padding 

LAMP Linux, Apache, MySQL, PHP 

LTE Long Term Evolution (mobile phone system) 

LWE Learning With Errors 

MAC Message Authentication Code 

MOV Menezes-Okamoto-Vanstone (attack) 

MPC Multi Party Computation 

MQV Menezes-Qu-Vanstone (protocol) 

MS Mobile Station (i.e. a phone in UMTS/LTE) 

NIST National Institute of Standards and Technology (US) 

NMAC Nested MAC 

NTRU A Post Quantum Encryption Algorithm 

OAEP Optimal Asymmetric Encryption Padding 

OCB Offset Code Book (mode) 

OFB Output Feedback (mode) 

OPE Order Preserving Encryption 

ORAM Oblivious Random Access Memory 

PACE Password Authenticated Connection Establishment 

PAK Password Authenticated Key (PAK) Exchange 

PAKE Password Authenticated Key Exchange 

PEKS Public Key Encryption Keyword Search 

PKCS Public Key Cryptography Standards 

PKE Public Key Encryption 

POR Proofs Of Retrievability 

PRF Pseudo Random Function 

PRNG Pseudo Random Number Generator 

PRP Pseudo Random Permutation 

PSEC Provable Secure Elliptic Curve (encryption) 

PSS Probabilistic Signature Scheme 

PV Pointcheval-Vaudenay (signatures) 

RC4 Ron's Cipher Four (a stream cipher) 

RDSA Russian Digital Signature Algorithm 

RFC Request For Comments 

RAM Random Access Memory 

ROM Random Oracle Model 

RSA Rivest-Shamir-Adleman 

SA Security Association 

SHA Secure Hash Algorithm 

SIMD Single Instruction Multiple Data 

SIV Synthetic Initialization Vector 

SK Sakai-Kasahara (ID-based encryption) 

SN Serving Network (i.e. a provider in UMTS/LTE) 

SPAKE Single-Party Public-Key Authenticated Key Exchange 

SPD Security Policy Database 

SQL Structured Query Language 

SSE Symmetric Searchable Encryption 

SSH Secure Shell 

SSL Secure Sockets Layer 

TKW Triple-DEA Key Wrap 

TDKW A Key Wrap Scheme 

TRNG True Random Number Generator 

UEA UMTS Encryption Algorithm 

UF Universally Unforgeable 

UIA UMTS Integrity Algorithm 

UMAC Universal hashing based MAC 

UMTS Universal Mobile Telecommunications System 

VPN Virtual Private Network 

WEP Wired Equivalent Privacy 

WPA Wi-Fi Protected Access 

XTS XEX Tweakable Block Cipher with Ciphertext Stealing 
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1 Introduction 

A cryptographic protocol is a procedure carried out between two parties which is used to perform 
some security task. Typically cryptographic protocols make use of one, or more, cryptographic 
primitives and/or schemes. An example might be the transmission of a credit card number from Bob 
to an e-commerce web site Alice. Such a protocol might involve a digital signature scheme (so Bob 
knows he is talking to Alice), and a form of encryption (to ensure Bob's credit card details are not 
intercepted in transit). Examples of deployed protocols which perform such operations are TLS or 
IPSec. 

Whilst the theory and design of cryptographic primitives and schemes (discussed in the sister report 
[115]) is relatively well established, and the feed through into deployed systems and products is 
progressing well, the same cannot be said for protocols. Due to the inherent complexity of the 
situations for which they are intended and the many subtleties that arise, cryptographic protocols are 
notoriously difficult to design, and even more difficult to analyse. 

In this document we outline the current knowledge on various classes of protocols. Our choice of 
protocols to cover is mainly dictated by what we feel is of most interest to the type of reader specified 
in the Executive Summary. Thus the protocols are either deployed in products, or are defined in 
standards and are hence planned to be deployed. Much of what we discuss in this report is likely to 
change as the research community shifts its focus to analysing protocols over the coming decade. The 
reader will hopefully also see by our analysis that most of the deployed protocols which can be used 
by a naive user, are in fact either incredibly complex to configure in a manner which we would deem 
secure, or are in fact insecure by modern cryptographic standards. 

How did such a poor state-of-affairs for the analysis of protocols arise? There are multiple answers to 
this question. Firstly, although academic researchers have put a large amount of effort in analysing 
protocols, the results are in settings that although informed and motivated by practice, do not 
immediately impact real uses of protocols. Some research, mainly that on formal methods (e.g. 
[88,275,298]) or the UC framework (e.g. [75]), aims to develop general frameworks for protocol 
analysis. However, concrete protocol analysis in such frameworks is confined to a small class of 
protocols (witness the numerous analyses of the Needham-Schroeder protocol [236]) or to generic 
results (for example general multi-party computation [138, 310]). Some academic results concern 
more specific classes of protocols such as key agreement [38]. However, this analysis has often been 
performed after the standards have been produced, and usually considers versions of the 
implemented protocols that are too simplified. 

A second reason is that practitioners usually adopt an ad-hoc design mentality for protocols. In this 
approach a protocol is designed according to some well-established principles and then one tries to 
find attacks; if attacks succeed, then a fix is suggested and new attacks are searched. This was 
acceptable in the early days of the subject, but now that we have formal theories to capture security 
definitions for protocols this approach does not seem adequate anymore. 

Thirdly, there is a certain (perhaps understandable) inertia that prevents practice from incorporating 
academic research. It is often the case that issues identified within the design of protocols already in 
place are dismissed as being only of "theoretical" interest, until the issues are exploited by a real 
attacker. Thus there is an inbuilt conservatism to not change anything, despite evidence that a given 
protocol may have a problem. This resistance to change can result in security vulnerabilities. 
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1.1 Designing and Verifying Protocols: Ideal World 

After having discussed what can go wrong, we now explain how things could be improved. Firstly, we 
note there are two schools as to how to verify a protocol; we refer to these loosely as the 
computational and the symbolic schools. 

• Computational School: In this school, often called the provable security school, a protocol is 
analysed according to some well-defined model. A complexity theoretic reduction is given which turns 
an adversary against the protocol into an adversary against a component. Thus the protocol is secure 
if all of its components are secure. To determine whether the component is secure (which is often a 
cryptographic scheme) a further reduction is provided to a cryptographic primitive. These reductions 
can be complex, with proofs being many pages long, and needing (currently) to be produced and 
verified by hand. 

• Symbolic School: In this school, often called the formal methods school, a protocol is analysed 
assuming perfect cryptography. The protocol is then abstractly described in, for example, a process 
algebra, with the attacker's goals being described by equations and the attacker's capabilities defined 
by equational theories. After this stage an automated checking process is applied to ensure that the 
attacker can never reach the stated goals. This type of analysis is often said to use the "Dolev-Yao" 
model [105]. 

Each school has its advantages and disadvantages. The first school has the disadvantage that it 
requires hand generated and checked proofs; on the other hand it models the cryptography and 
adversary as close to the real world as possible. The second school has the disadvantage that it 
assumes perfect cryptography (which we know is not possible in real systems), but it allows for tools 
that automate devising proofs, or at the very least checking them [54, 91, 218, 258]. 

In recent years there has been some progress towards using the best of both worlds. For some 
protocols the theory of computational soundness will imply that a protocol shown to be secure in the 
symbolic method will also be secure in the computational model [6, 89]. However, this method only 
applies to a restricted set of protocols. In the other direction, some researchers are applying the 
techniques from the symbolic school to try to automate the proof generation methods in the 
computational school [27, 28, 55]. However, both of these techniques are still in their infancy. 

A major problem is that whatever method is used an actual protocol may not follow the abstract 
specification which is analysed. The process, known as idealisation, of turning a protocol specification 
as found in a standard into one which is analysable by any of the above techniques is notoriously error 
prone. 

Thus the "correct" way for a protocol to be designed is for a specification to be given, which allows for 
it to be easily translated into an abstract specification. Then the protocol should be analysed using the 
techniques of either of the above schools. The designer should feedback lessons learned from the 
analysis into the protocol design and the process should be repeated. 

At the end, if analysis has been performed with symbolic methods, and computational soundness 
results do not apply, then we can conclude that the protocol has no structural weaknesses and no 
obvious attacks. If computational soundness results do apply, or the protocol has been proved secure 
in the computational school, then we can conclude that the protocol is secure with respect to the given 
computational security model. This latter point means that any insecurity will either be one of 
implementation or uses an attack vector which was not captured by the security model. 
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1.2 Designing and Verifying Protocols: Real World 

In the real world protocols are almost always designed, deployed, patched and extended before any 
formal analysis of their properties happens. This is either for historic reasons (the protocols date to a 
time before verification techniques were understood), or for business reasons (for example a protocol 
is defined "in house" and only then is made public for public analysis, after a product has been 
produced). Thus formal verification using either symbolic or computational means is often applied 
post-hoc. 

Often this post-hoc analysis finds faults in the standardised/deployed protocols (see for example our 
discussion of ISO 9798 in Section 2.2) or it can only be applied to small subsets of the actual protocol 
(see for example our discussion of TLS in Section 3.1). In the latter case one can obtain verification of 
the small part, but not of the whole protocol. 

A major problem with protocols is the question of composition. A protocol which is secure when run 
in isolation may not be secure if run in composition (either sequentially or in parallel). Since most 
protocols are run in an online environment, with multiple executions happening at any one time, the 
issue of parallel composition is vital to ensure. Theoretically, techniques exist to enable composition 
of protocols to be designed in from the start, for example the UC Framework [75]. However, the 
analysis of most existing protocols has been carried out in the standalone setting, which may result in 
attacks in practical situations. 

1.3 How to Read This Document 

We divide our discussion on protocols into four sub-themes: 

• General Protocols: These are protocols which are designed to meet some general security 
requirement and which can be used in a multitude of applications. They are generally simple stand- 
alone protocols with no "reference" implementation or deployment; examples include: General key 
agreement and general identification. 

• Specific Protocols: These are protocols which often implement some well specified security 
requirement, but for which there are well known instantiations. These protocols are ones which can 
be used to provide various application services depending on the specific environment in which they 
are deployed; examples include: TLS and Kerberos. 

• Application Specific Protocols: These are protocols which are designed for a tightly defined specific 
application; examples include: UMTS/LTE, WEP/WPA and ZigBee. 

• Application Areas: These are areas to which various protocols can be applied, and for which ENISA 
specifically requested a discussion. In this document this section focuses on the area of cloud 
computing. 

To understand the distinction between the latter three cases consider the following: Application 
developers often choose to use TLS as a means to securing a channel between applications, and the 
various parameters can then be selected by the developer; irrespective of whether the application is 
providing a web service or not. On the other hand, one is forced to use the mobile phone protocols 
UMTS/LTE if one wishes to use a standard mobile phone, with provider mandated parameters and 
algorithms. In addition the use of UMTS/LTE outside this application is very limited. Clearly this division 
is not complete, as in some sense one is also forced to use TLS when accessing secure web sites, but 
the usage of TLS is much wider than that. In particular TLS can be used in the context of cloud 
computing to secure connections from a client to a cloud, or between cloud installations. 

Protocol choices also depend on the specific environment being considered. In this version of the 
report, at the request of ENISA, we include a section detailing issues related to the environment which 
has been called "Cloud Computing". 
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2 General Protocols 

In this section we detail some protocol classes; which on their own have been specified in standards 
but for which we know of no concrete implementation. Thus we call them general protocols as they 
essentially specify classes of protocols; some of which are then instantiated in Section 3 on Specific 
Protocols. 

For each protocol class we specify a general description, standardization efforts, and limitations and 
then we give technical details. 

2.1 Key Agreement 

General Description: A key agreement protocol allows two parties to agree on a shared secret key. 
There are various properties which may hold in a protocol; for example, one or both parties may end 
up being authenticated to the other, the protocol may guarantee a random key is output even if one 
party is compromised, and so on. Authentication of parties is generally obtained by parties holding a 
static public/private key pair, which are used in multiple sessions. Any key pairs used in a specific 
session are called ephemeral keys. An important distinction is between key transport where one party 
generates a key and sends it to the other, and key agreement where neither party has complete 
control over the key generation process. 

We first discuss key agreement, since this is the one area in which there has been a rigorous analysis 
of protocols; with concrete security definitions being given. Despite this, the situation in relation to 
how these security definitions map onto real world protocols and their usages is still in a state of flux. 

Standardization Efforts: The NIST standard [240] (resp. [241]) and the ANSI standards [20, 22] (resp. 
[21]) define methods for general key agreement using discrete logarithm based systems (resp. 
factoring based systems). The standard [240] introduces a nice taxonomy for such schemes with the 
notation C(a, b), where a, b E{0, 1, 2}. The number a refers to how many of the two parties contribute 
ephemeral keys to the calculation and the number b refers to how many of the two parties are 
authenticated by long term public/private key pairs. For example, traditional non- authenticated 
Diffie-Hellman is of type C(2,0), whereas traditional MQV [206] is of type C(2,2). The standards also 
provide various mechanisms for key confirmation. 

There are a sequence of standards in the ISO/IEC 11770 series, which mirror the ISO/IEC 9798 series 
discussed below. The main set (ISO/IEC 11770-2,-3, and -4) detail mechanisms involving symmetric 
encipherment techniques [163], public key techniques [164], and weak secrets (such as passwords) 
[165]. 

Limitations: The general standards on key agreement mentioned above are very general. The reader 
should refer to the TLS, IPSec, etc discussions in Section 3 for examples of such protocols in more 
detail. 

Technical Details: The security of key agreement schemes is somewhat complicated. The traditional 
security models of Bellare, Rogaway, et al base security on indistinguishablity of keys [37, 38, 53, 79]. 
This property is often not satisfied by real world protocols, and in particular by protocols using key 
confirmation. This issue has started to be treated in a number of works focusing on the TLS protocol 
(see below). Also discussion of the notion of one-sided authentication in key agreement protocols has 
only recently been considered in the academic literature [74,199]. Thus many of the options in these 
standards cannot be said to have fully elaborated proofs of security which are applicable in general 
situations. 

The precise choice of which key agreement scheme to use is therefore highly dictated by the 
underlying application. However, the sister report to this one [115] can be used to determine key sizes 
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(for the underlying factoring and discrete logarithm based primitives) as well as the key derivation 
functions, MAC functions and any other basic cryptographic components used. 

Finally, a crucial requirement which is becoming more important in the real world is that of forward 
secrecy. A key agreement scheme is said to be forward secure if the compromise of the long term 
static private key of a party does not compromise the confidentiality of the agreed key for sessions 
which occurred prior to the compromise of the key. Thus we are ensured that the key agreed now will 
be secure against any future compromise of the static keys. 

2.2 Identification and Authentication Protocols 

General Description: Identification protocols are protocols which enable a party to establish in an 
online protocol that they are both "live" and the claimed person at the other end of the 
communication. As such, parties have a static secret or private key whose possession is being verified. 
This static key may either be associated to the known static public key, or may be a shared secret held 
between the person verifying their identity and the person proving their identity. 

In this work we make no distinction between identification and user authentication; however in some 
applications (for example those based on biometrics) the distinction is important. In general, in an 
authentication protocol we are aiming to verify the person against a known claimed identity, in an 
identification protocol the verifier is not given the claimed identity 1 and needs to also output this 
value. Thus, identification means a way of determining who someone is from a given population, 
whereas authentication means confirming a claimed identity. 

Identification and user authentication are closely related to the topic of key agreement. Indeed in the 
academic key agreement literature these are often treated at the same time, see for example [79]. 
The reason for this linkage is that key agreement without user identification achieves relatively little. 
In addition, often keys are agreed for the primary purpose of authenticating a subsequent 
communication without the need to perform expensive public key operations on each 
communication. However, in terms of applications the usage of identification and authentication 
techniques have wider impact; for example in access to resources and/or physical settings. 

Standardization Efforts: The main standards in this area are the ISO/IEC 9798 series [168-173]. The 
main set (ISO/IEC 9798-2,-3, and -4) detail mechanisms involving symmetric encipherment (i.e. 
encrypting a challenge under a secret key as a means of authentication) [169], those involving a 
cryptographic check function (i.e. applying a MAC function to a challenge as a means of 
authentication) [170], and those involving a digital signature (i.e. signing a given challenge as a means 
of authentication) [171]. 

Limitations: The standards in the ISO/IEC 9798 series are mainly "folklore" and as such their analysis 
has only recently been performed in the academic literature. Work in the provable security tradition 
was first performed as early as 2001 [34], despite this the original standards contained numerous 
problems which were identified in 2011 [29, 30] using the symbolic tradition. See below for an 
extensive discussion on this point. 

Technical Details: The problems identified in [29, 30] were identified using a tool called SCYTHER, 
which found the weaknesses and determined whether proposed fixes were correct. A related tool 
called SCYTHER-PROOF was used to produce proof scripts which were then machine-checked using 
the Isabelle/HOL theorem prover. Various problems were identified including role-mixup attacks, type 
flaws, and reflection attacks; most of the flaws resulted from poor specification of message formats 
or crucial missing fields. Thus data intended for one person could be routed to another, or data 



1 They know however, for example, that the identifying party claims to have an identity in some given database. 
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elements could be interpreted in different ways. The standards have since been revised to take into 
account the problems identified, but the analysis is a lesson in the importance of applying modern 
scientific techniques to protocol design as opposed to relying on folklore. As mentioned the analysis 
in [29, 30] is purely in the symbolic tradition. Thus we obtain guarantees of correctness and the 
identification of logical weaknesses. To our knowledge, no systematic analysis has been done in the 
computational tradition; nor has an analysis been conducted as to whether computational soundness 
results can be applied to the existing symbolic analysis. Clearly some of the protocols in ISO/IEC 9798- 
2, -3, and -4 have been analysed in the academic literature in a computational manner but this is not 
documented well, and there is always the issue of problems related to idealisation between the 
definition in the standard and the definition used in the academic literature. 

The standard ISO/IEC 9798-5 [172] details protocols based on zero-knowledge techniques. Due to the 
difficulty of dealing with these using symbolic methods, these are not analysed in [29, 30]. However, 
all of the protocols in this standard have appeared in the academic literature with computational 
proofs of security. All of the basic techniques are based on the ideas behind the Fiat-Shamir 
identification scheme [117], and the closely related Guillou-Quisquater scheme [144]. In these 
protocols a user is identified by showing knowledge of some secret value which has been committed 
in their identifying information (e.g. by showing knowledge of a private key associated to a public key). 
As well as these "classic" methods the standard also contains the schemes of Girault, Poupard and 
Stern [133, 265], Girault and Pailles [134], Brandt et al [69] and Mitchell and Yuan [227]. The technique 
of Girault, Poupard and Stern [133, 265] also appears in ISO/IEC 29192-4 [166], which focuses on 
lightweight cryptographic techniques. 

Despite being based on provably secure protocols there has been (to our knowledge) no analysis as to 
whether the idealisation process between the specification and the prior analysed protocols is correct, 
nor whether the protocols as specified are subject to type attacks (since the standardised protocols 
introduce many fields for various application specific reasons). 

Standard ISO 9798-6 [173] examines mechanisms which utilise the need of a human operator to 
manually transfer a short data string from one device to another, or to manually verify that two short 
data strings are identical. The standard makes no reference to academic literature, although there is 
an extensive literature in this space, [25, 136, 181, 203-205,222,223,234,235,250,251,271, 292, 303]. 

2.3 Password Authenticated Key Exchange Protocols 

General Description: Just like in key-agreement, password-based key exchange protocols (PAKEs) 
allow two parties to share a key. The difference is that the authentication of the entities involved in 
the exchange relies on passwords shared between clients and servers (thus reducing the dependence 
on a PKI). The challenge is to design protocols that are secure against off-line dictionary attacks - 
attacks where adversaries infer information about the password only from the transcripts of protocol 
executions. The guarantee one wants is that an adversary cannot impersonate a user except if he 
successfully guesses a password. 

Standardization Efforts: There has been some standardization of PAKE protocols. But these are usually 
relatively limited in terms of application areas, being tied to a specific application, or have limited (if 
any) take up. 

Limitations: Despite their intuitive usefulness there has been little take up in the real world of PAKE 
protocols. One reason, which is often cited for this, is the existence of a general patent on the EKE 
protocol. It may be useful to note that the patent on the EKE protocol expired in 2011 

Technical Details: Syntactically, PAKE protocols fall in two classes, balanced and augmented. In 
balanced PAKEs the server and the users share passwords, whereas in augmented PAKEs (or verifier- 
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based PAKEs) the server has only a one-way function of the passwords (e.g. a hash of the passwords). 
The latter are preferable as they offer some degree of security even in face of a complete server 
breach. 

Two types of models are used in the security analysis of these protocols. The model proposed by 
Bellare, Pointcheval, and Rogaway (henceforth the BPR model) [37] is an indistinguishablity based 
model that builds on the ideas in [38]. There are two types of simulation based models, one due to 
Boyko, MacKenzie and Patel (henceforth the BMP model) [65], which in turn build on those of Bellare, 
Canetti, and Krawczyk [33] and Shoup [286], and one due to Canetti et al. (henceforth the CHKLM 
model) [78], which builds on the Universal Composability framework [75]. We start with an overview 
of existent efficient protocols in the Random Oracle Model, with Figure 3.1 summarising the 
discussion. 

The seminal protocol in this area is the Encrypted Key Exchange (EKE) protocol of Bellovin and Merritt 
[41], followed by an augmented version [42]. The security of the protocol had been first analysed by 
Bellare et al. [37] but the analysis relies on the strong ideal cipher model. Slight variations that aim to 
preserve the efficiency of the protocol but reduce the assumptions needed in the proof have later 
been provided [70, 71]. The most efficient protocol that resulted from this line of work is the SPAKE 
protocol due to Abdalla and Pointcheval [9]; the protocol has a security analysis in the random oracle 
model. 

The SPEKE B-SPEKE protocols proposed by David Jablon [174, 175] were two of the first proposed 
protocols following the publication of EKE. MacKenzie provides an analysis of SPEKE in a restricted 
variant of the BPR model [219] (the mBPR model). In a similar vein Boyko, MacKenzie and Patel [65] 
proposed PAK and prove it secure in the BMP model assuming the random oracle. They also provide 
an augmented version called PAK-X. 

In contrast to the above protocols, the PACE protocol is one which was designed for a specific 
application. It was proposed by the German Federal Office for Information Security, and is intended 
for deployment in machine readable travel documents, and protocol is fully specified in standards, 
e.g. in [198]. The protocol has a security proof with respect to (a variant) of the BPR model. The proof 
assumes both random oracles and ideal ciphers [44]. 
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Figure 2.1: Summary of PAKE in the Random Oracle Model (ROM) and Ideal Cipher Model (ICM 



Some other protocols that have gained some traction recently (mainly as IP free alternatives) are J- 
PAKE [147] and Dragonfly [149]. Claims of security for these protocols are however not supported by 
fully worked-out proofs. 

Just like for any other primitive/protocol PAKE protocols secure in the standard model, i.e. ones not 
using random oracles, are not very efficient; to the point where they are not really practical. A series 
of works starting with the protocol of Katz, Ostrovsky and Yung [185] and the more general framework 
of Goldreich and Lindell [137] propose PAKEs that are secure in the standard model. These protocols 
which include those in [8, 10, 26] but are significantly less efficient than those discussed above. 
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3 Specific Protocols 

In this section we detail general purpose protocols for accomplishing various tasks, which can be used, 
and are, used in multiple application scenarios. Whilst the protocols here were designed for specific 
tasks (for example TLS was designed to secure communication between a browser and a web site) 
they can, and are, used for other applications. 



General Description: The TLS protocol (the current version being vl.2) is primarily aimed at securing 
traffic between an unauthenticated web browser and an authenticated web site, although the 
protocol is now often used in other applications due in part to the availability (and ease of use) of a 
variety of libraries implementing TLS. The TLS protocol suite aims to provide a confidential channel 
rather than simply a key agreement protocol as discussed before in Section 2.1. The protocol is broken 
up into two phases: A handshake (or key agreement) phase and a record layer encryption phase. 

Standardization Efforts: The protocol has been standardised by the IETF in various standards, of which 
we list just some [52,101-103,224,279]. The genesis of the protocol dates back to SSL vl.O, in 1993, 
and its current complex state is a symptom of both issues related to backward compatibility and 
mission creep. The protocol is currently undergoing a major revision so as to produce TLS vl.3. 

A complete list of ciphersuites for TLS is listed at the website http://www.iana.org/assignments/ tls- 
parameters/tls-parameters.xml. If following the recommendations of this document, the restrictions 
on the ciphersuites to conform to our guidelines for future systems means this large list becomes 
relatively small. We provide guidelines on specific ciphersuites, for both the hand- shake and record 
layer transport phases, below. 

Limitations: Due to the non-systematic development process, the protocol is hard to analyse and 
easily prone to implementation weaknesses. Below we summarise the latest knowledge in this regard. 
Care must be taken in long term key generation as a number of TLS implementations have been shown 
to be weak due to poor random number generation, see [151] and [115][Section 6.2]. 

Technical Details: The handshake/key agreement phase has now been fairly thoroughly analysed in a 
variety of works [73, 176, 177, 199, 231]. A major issue in these analyses is the use of the derived key 
during key confirmation via the FINISHED messages. 

The handshake/key agreement phase runs in one of essentially two main modes: either RSA- based 
key transport or Diffie-Hellman key exchange (an option also exists for pre-shared keys). The RSA key 
transport methodology uses RSA-PKCS#1 vl.5, which is discussed in [115][Section 4.6.1] is not 
considered secure in a modern sense. However, the use of this key transport methodology has been 
specifically patched in TLS to avoid the attack described in [56], and a formal security analysis 
supporting this approach in the TLS context can be found in [199]. This latter analysis shows that key 
transport in TLS can be made secure (but not forward secure) under a sufficiently strong number 
theoretic assumption and in the Random Oracle Model. The Diffie-Hellman based key agreement 
mode is considered much more secure, and offers the benefit of perfect forward secrecy of the agreed 
key. In both modes the output of the key agreement phase is a so-called pre-master secret. 

For the handshake part of the protocol the principle issue is that the RSA signing algorithm in TLS 1.2 
is RSA-PKCS# 1 vl.5. Since most certificates issued are certificates on RSA keys, this means that RSA- 
PKCS# 1 vl.5 is the default signing algorithm for use in TLS. As explained in [115][Section 4.8.1] we do 
not advise the use of this signature scheme in future systems. 

Considering the discrete logarithm or elliptic curve signature variants, one finds that the situation is a 
little better. The required signature algorithm here is (EC)DSA, which also has no proof of security, bar 
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in the generic group model for the elliptic curve variant. See [115][Section 4.8.5] for more details. Thus 
for the key negotiation phase one is left to rely on cryptographic schemes which we only suggest for 
legacy use. 

Given these caveats, we advise the following key exchange methods for legacy use in TLS as they 
provide forward secrecy 

• TLS_DHE_DSS_WITH_*, 

• TLS_DHE_RSA_WITH_*, 

• TLS_ECDHE_ECDSA_WITH_*, 

• TLS_ECDHE_RSA_WITH_*, 

Where the ★ suffix denotes an underlying record layer encryption method. The only thing which stops 
us recommending any key exchange methods for future use is the lack of a provably secure public key 
signature algorithm within the available choices. Of the four choices TLS_ECDHE_ECDSA_WITH_* is 
probably to be preferred as ECDSA signatures are more likely to be secure in the long run than the 
RSA method. 

In TLS 1.3 it is proposed to remove the key transport (i.e. RSA variant) and only have forward secure 
key agreement phases. In particular this would mean that long term public keys are only used to 
provide key authentication and are not used to provide key confidentiality. This change, as well as 
being good security practice, has been accelerated since summer 2013 due to the Snowden 
revelations. 

During the handshake phase the key to use in the transport layer is derived from the agreed pre- 
master secret. This derivation occurs in one of two ways, depending on whether TLS 1.2 [103] is used 
or whether an earlier standard is used (TLS 1.0 [102] and TLS 1.1 [102]). As discussed in [115][Section 
4.4.5], the use of TLS-vl.l-KDF should only be used for legacy applications, with the TLS-vl.2-KDF 
variant being considered suitable for future applications. 

The record layer, i.e. the layer in which actual encrypted messages are sent and received, has received 
extensive analysis. In TLS 1.0 and TLS 1.1 the two choices are either MAC-then-Encode- then-Encrypt 
using a block cipher in CBC mode or the use of MAC-then-Encrypt using the RC4 stream cipher. Both 
these forms of the record layer have been shown to be problematic [16,17,81, 255,302]. The main 
problems here are that the MAC-then-Encode-then-Encrypt construction used in TLS is difficult to 
implement securely (and hard to provide positive security results about), and that RC4 is, by modern 
standards, a weak stream cipher. These issues are partially corrected in TLS 1.2 [103] by adding 
support for Authenticated Encryption, and with GCM mode and CCM mode for TLS being specified in 
[279] and [224], respectively. Other recent attacks include those by Duong and Rizzo, known as BEAST 
[107] and CRIME [108]. BEAST exploits the use of chained IVs in CBC mode in TLS 1.0, and CRIME takes 
advantage of information leakage from the optional use of data compression in TLS. In TLS 1.3 it is 
proposed that only AEAD methods are used to secure the record layer. 

Looking at the record layer protocol (i.e. the algorithms to encrypt the actual data), we see that only 
the use of Camellia and AES, within a mode such as GCM or CCM, are compatible with the guidelines 
in [115], This means at the time of writing we would only advise the following cipher suites, for the 
record layer for future (and legacy) use within TLS 

• *_WITH_Camellia_128_GCM_SHA256, 

• *_WITH_AES_128_GCM_SHA256, 

• *_WITH_Camellia_256_GCM_SHA384, 
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• *_WITH_AES_256_GCM_SHA384, 

• *_WITH_AES_128_CCM, 

• *_WITH_AES_128_CCM_8, 

• ★_WITH_AES_256_CCM, 

• *_WITH_AES_256_CCM_8. 

where the ★ prefix denotes an underlying key exchange method. 

Given the above discussion it is hard to recommend that TLS 1.0 and TLS 1.1 be used in any new 
application, and phasing out their use in legacy applications is advised. It would appear that TLS 1.2 is 
sufficient for future applications. However, there are currently very few implementations of clients, 
servers, or libraries which support TLS 1.2, although this is now increasing rapidly. 



General Description: Secure Shell (SSH) was originally designed as a replacement for insecure remote 
shell protocols such as telnet. It has now become a more general purpose tool that is used to provide 
a secure channel between two networked computers for applications such as secure file transfer. In 
general the host one is connecting to is authenticated, whereas the client is not (although some 
corporations do insist on client side authentication for SSH usage). 

Standardization Efforts: SSHv2 was standardised in a collection of RFCs [312-314] in 2006, other 
relevant standards are [32, 48, 93, 162, 215, 215]. The original version, SSHvl has several design flaws 
and should no longer be used. OpenSSH [242] is the most widely used implementation of the protocol. 
In 2008 it accounted for more than 80% of all implementations. The transport layer of SSH [314] is 
responsible for the initial key-exchange, server authentication and, confidentiality and integrity of 
messages sent on the channel. 

Limitations: The main issue with SSH, much like TLS above, is that most of the standard encryption 
algorithms for the transport layer are not sufficient to ensure complete security. They possess a 
number of cryptographic weaknesses, which would not exist if the protocol choices had been made 
more recently. See the following section for a technical discussion on these matters, as well as 
guidelines for going forward. 

Technical Details: The key-exchange protocol is based on Diffie-Hellman and host authentication is 
provided by combining this with a signature. Client authentication is also possible but defined in a 
separate RFC [312]. Methods for authenticating the client are either using a password, public- key 
cryptography (DSA, RSA, X.509), an "interactive-keyboard" challenge-response method [93] or the 
GSSAPI [215] which allows the use of external mechanisms such as Kerberos. Support for the key- 
exchange methods, dif f ie-hellman-groupl-shal and dif f ie-hellman-groupl4- 
shal is mandated by the RFC [314]. These methods use the Oakley Group 1 (1024-bit prime field) 
and Oakley Group 14 (2048-bit prime field) [195]. RFC4419 [123] describes a key-exchange method 
for SSH that allows the server to propose new groups on which to perform the Diffie-Hellman key 
exchange with the client. RFC4432 [150] specifies a key-transport method for SSH based on 1024- bit 
and 2048-bit RSA. RFC5656 [293] defines introduces support for Elliptic-Curve Cryptography; detailing 
support for ECDH and ECMQV. 

Williams [309] has performed an analysis of the key-exchange methods in SSH. It has been shown the 
six application keys (two IV keys, two encryption keys and two integrity keys) generated by the 
protocol and passed to the next stage of the SSH protocol are indistinguishable from random. The 
analysis assumes the server's public key is validated through a certificate from some secure public- 
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key infrastructure. The author of [309] notes that if no such certificate is used, then the protocol is 
vulnerable to attack, unless the client has some other method of verifying the authenticity of a server's 
public key. 

Once keys are established all message are then sent encrypted over the channel using the Binary- 
Packet Protocol (BPP) [314, Section 6]. This specifies an encryption scheme based on an Encode- then- 
Encrypt-and-MAC construction using a block cipher in CBC mode or the stream cipher RC4. The encode 
function specifies two length fields which must be prepended to messages prior to encryption and a 
padding scheme (for the case of CBC mode). The first length field specifies the total length of the 
packet and the second gives the total length of padding used. The specification recommends using 
CBC mode with chained IVs (the last block of the previous ciphertext becomes the IV of the following 
ciphertext). This has been shown to be insecure by Dai [94] and Rogaway [273]. Albrecht et al. [15] 
were able to perform plaintext-recovery attacks against SSH (when using CBC mode) by exploiting the 
use of encrypted length fields. As a result of these attacks we state that CBC mode should not be used. 
We note that OpenSSH Version 6.2 [242] supports a non- standard version of the BPP for use with CBC 
mode in an Encrypt-then-MAC construction where length fields are not encrypted but still 
authenticated. This style of construction would be secure against the Albrecht et al. attack. 

A first formal security analysis of the SSH-BPP was performed by Bellare et al. [36]. As a result of the 
Albrecht et al. attacks this security analysis was proved to be incomplete and a further security 
analysis, which more closely matched actual implementations of SSH, was performed by Paterson and 
Watson [256]. They proved that the Encode-then-Encrypt-and-MAC construction utilising counter 
mode encryption is secure against a large class of attacks including those of Albrecht et al. We advise 
counter mode as the best choice of available cipher in the Encode-then-Encrypt- and-MAC 
construction when combined with a secure MAC algorithm. The original choice of MAC algorithms 
specified in RFC4253 was limited to HMAC with either SHA-1 or MD5. We advise neither of these hash 
functions for current use. RFC6668 [48] details the use of SHA-2 for HMAC. In addition to the Encode- 
then-Encrypt-and-MAC construction confidentiality and integrity in SSH may also be provided by GCM 
encryption as specified in RFC5647 [162]. 

A complete list of ciphersuites for SSH is listed at the website http://www.iana.org/assignments/ssh- 
parameters/ssh-parameters.xml . 

Based on the guidelines of this document we would only advise the following encryption and MAC 
algorithms, for future use within SSH: 

• aesl28-ctr with hmac-sha2-256 or hmac-sha2-512 

• aesl92-ctr with hmac-sha2-256 or hmac-sha2-512 

• aes256-ctr with hmac-sha2-256 or hmac-sha2-512 

• AEAD_AES_128_GCM 

• AEAD AES 256 GCM 



General Description: IPSec is designed to provide security at the IP network layer of the TCP/IP 
protocol stack. This differs from protocols such as TLS and SSH, above, which provide security at higher 
layers such as the application layer. This is advantageous since no re-engineering of the applications 
is required to benefit from the security IPSec provides. The main use of IPSec has been to create virtual 
private networks (VPNs) which facilitates secure communication over an untrusted network such as 
the Internet. 



3.3 IPSec 



Page 11 




Study on cryptographic protocols 



November, 2014 



The IPSec protocols can be deployed in two basic modes: tunnel and transport. In tunnel mode 
cryptographic protection is provided for entire IP packets. In essence, a whole packet (plus security 
fields) is treated as the new payload of an outer IP packet, with its own header, called the outer 
header. The original, or inner, IP packet is said to be encapsulated within the outer IP packet. In tunnel 
mode, IPSec processing is typically performed at security gateways (e.g. perimeter firewalls or routers) 
on behalf of endpoint hosts. By contrast, in transport mode, the header of the original packet itself is 
preserved, some security fields are inserted, and the payload together with some header fields 
undergo cryptographic processing. Transport mode is typically used when end-to- end security 
services are needed, and provides protection mostly for the packet payload. In either mode, one can 
think of the IPSec implementation as intercepting normal IP packets and performing processing on 
them before passing them on (to the network interface layer in the case of outbound processing, or 
to the upper layers in the case of inbound processing). 

Standardization Efforts: The protocol was originally standardised in a collection of RFCs in 1995 and 
their third incarnation can be found in RFCs 4301-4309 [110,153,155,187,190-193,280]. For a more 
complete description of the cryptography in the IPSec standards we refer the reader to the survey by 
Paterson [252]. 

Limitations: The key agreement phase of IPSec, called IKE, is well studied and well defined. As for TLS 
and SSH the payload encryption algorithms have had a number of issues over the years, related to 
poor acceptance of the need for AEAD/IND-CCA encryption algorithms. More details are provided in 
the technical section below. 

Technical Details: Each IPSec implementation contains a Security Policy Database (SPD), each entry of 
which defines processing rules for certain types of traffic. Each entry in the SPD points to one or more 
Security Associations (SAs) (or the need to establish new SAs). The SAs contain (amongst other 
information) cryptographic keys, initialisation vectors and anti-replay counters, all of which must be 
initialised and shared between appropriate parties securely. This can be solved manually, and such an 
approach works well for small-scale deployments for testing purposes. 

However, for larger scale and more robust use of IPSec, an automated method is needed. The Internet 
Key Exchange (IKE) Protocol provides the preferred method for SA negotiation and associated 
cryptographic parameter establishment. The latest version of IKE, named IKEv2 [188], provides a 
flexible set of methods for authentication and establishment of keys and other parameters, supporting 
both asymmetric and symmetric cryptographic methods. There were initially two Diffie-Hellman 
Groups defined for use in IKEv2 [188, Appendix B], one with a 768-bit modulus the other with 1024- 
bit modulus. Further DH groups are defined in RFC3526 [195] of sizes 1536, 2048, 3072, 4096, 6144 
and 8192 bits. Elliptic Curve groups are defined in RFC 5903 [124] with sizes of 256, 384 and 521 bits. 
RFC5114 [208] defines an additional 8 groups. Based on [115][Section 3.5] we advise for future use a 
group size of at least 3072 bits, and 256 bits in the case of elliptic curve groups. For key derivation, as 
discussed in [115][Section 4.4.4], the use of IKE-vl-KDF should only be used for legacy applications, 
with the IKE-v2-KDF variant being considered suitable for future applications. 

There are two main IPSec protocols which specify the actual cryptographic processing applied to 
packets. These are called Authentication Header (AH) and Encapsulating Security Payload (ESP). 

AH provides integrity protection, data origin authentication and anti-replay services for packets 
through the application of MAC algorithms and the inclusion of sequence numbers in packets. There 
are a number of MAC algorithms defined for use with IPSec. These include HMAC (with MD5 [220], 
SHA-1 [221] or SHA-2 [189]), GMAC [225] and XCBC (a CBC-MAC variant) [121]. Based on earlier 
sections we only advise HMAC with SHA-2 for future use. 
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ESP provides similar services to AH (though the coverage of its optional integrity protection feature is 
more limited) and in addition provides confidentiality and traffic flow confidentiality services through 
symmetric key encryption and variable length padding of packets. ESP allows both encryption-only 
and authenticated encryption modes. The attacks we shall mention in the following paragraph 
demonstrate the encryption-only modes should not be used. ESP must therefore always be configured 
with some form of integrity protection. The encryption algorithms on offer are CBC mode (with either 
3DES [259], AES [120] or Camellia [184]), CTR mode (with either AES [154] or Camellia [184]). Of these 
algorithms we would only advise CTR mode and stress it must be combined with a MAC algorithm. 
Further options for authentication encryption are provided by the combined algorithms CCM (with 
either AES [155] or Camellia [184]) and GCM with AES [155]. 

An initial analysis of the IPSec standards was performed by Ferguson and Schneier [116]. This was 
followed by Bellovin [40] who found a number of attacks against encryption-only ESP. Practical attacks 
were demonstrated by Paterson and Yau [257] against the Linux implementation of IPSec where 
encryption-only ESP was operating in tunnel mode. By adapting the padding oracle attack of Vaudenay 
[302], Degabriele and Paterson were then able to break standards-compliant implementations of 
IPSec [99] with practical complexities. These attacks were against encryption-only ESP using CBC mode 
and operating in either tunnel or transport mode. From these attacks, the need to use some form of 
integrity protection in IPSec is evident. It is therefore recommended that encryption-only ESP not be 
used. A further set of attacks by Degabriele and Paterson [100] breaks IPSec when it is implemented 
in any MAC-then-Encrypt configuration (for example, if AH in transport mode is used prior to 
encryption-only ESP in tunnel mode). On the other hand, no attacks are known if ESP is followed by 
AH, or if ESP's innate integrity protection feature is used. To conclude, we reiterate that ESP should 
always be used with some form of integrity protection, and that care is needed to ensure an 
appropriate form of integrity protection is provided. 

A close to complete list of ciphersuites for IPSec is listed at the website 
http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml . 

Based on the guidelines in [115] we would only advise the following algorithms for future use within 



• If only authentication is required then either AH or ESP may be used with one of the following 
MAC algorithms as defined in RFC4868 [189]. 

- HMAC-SHA2-256, 

- HMAC-SHA2-384, 

- HMAC-SHA2-512, 

• If confidentiality is required then ESP should be used by combining one of the following 
encryption algorithms with one of the MAC algorithms described above. 

- AES-CTR, 

- CAMELLIA-CTR, 

• Alternatively one of the following combined authenticated encryption modes may be used: 

- AES-CCM_*, 

- CAMELLIA-CCM_*, 

- AES-GCM_*, 

Here, the * denotes the size (in bytes) of the integrity check value (ICV) and we advise choosing either 



IPSec 



12 or 16. 
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3.4 Kerberos 

General Description: Kerberos is an authentication service which allows a client to authenticate his or 
herself to multiple services e.g. a file server or a printer. The system uses a trusted authentication 
server which will grant tickets to participating parties allowing them to prove their identity to each 
other. It is primarily based on symmetric-key primitives; the specific construction being derived from 
the Needham-Schroeder Protocol [236]. Public-key primitives, namely RSA signatures, may also be 
used during the initial authentication phase [319]. 

Standardization Efforts: Kerberos was designed as part of project Athena at MIT during the 1980s 
[226]; the first three versions were not released publicly; Version 4 can therefore be viewed as the 
"original" release. The current version, Version 5 [237], fixed a number of security deficiencies present 
in its predecessor [39]. Version 4 required the use of DES; Version 5 expanded the possible ciphers 
and AES is now supported [269]. 

Limitations: Again there are issues related to the usage of strong encryption schemes (i.e. AEAD/IND- 
CCA schemes) due to the age of the documents defining the protocol. 

Technical Details: Version 4 made use of a non-standard version of CBC mode called PCBC which has 
been shown to be insecure [196]. The encryption scheme used by Version 5 has been formally 
analysed by Boldyreva and Kumar [61], who first show that the Encode-then-Checksum- then-Encrypt 
construction defined in RFC3961 [270] does not meet the INT-CTXT definition of security. If a secure 
MAC algorithm is used for the checksum then this construction will be secure. Additionally, Boldyreva 
and Kumar analyse the Encode-then-Encrypt-and-MAC construction given in RFC3962 [269] and show 
this to be secure assuming the underlying primitives meet standard definitions of security. The 
encryption scheme specified for use in Version 5 is CBC mode with ciphertext stealing using either 
DES, 3DES [270], AES [269] or Camellia [157] as the underlying blockcipher. 

A complete list of ciphersuites for Kerberos is listed at the website 
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xml . At the time of 
writing we advise the following ciphersuites for future use within Kerberos: 

• aesl28-cts-hmac-shal-96 

• aes256-cts-hmac-shal-96 

• camellial28-cts-cmac 

• camellia256-cts-cmac 
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4 Application Specific Protocols 

In this section we present a quick overview of protocols which are used in relatively restricted 
application areas; for example wireless, mobile communications or banking. 



General Description: The WEP/WPA protocols are used to protect communication in wireless 
networks; for example in securing the communication between a laptop and the wireless router (a.k.a 
access point) to which it connects. The key design requirement is to ensure that an eavesdropper is 
unable to break the confidentiality of the messages being sent. We discuss their use in the setting 
where the device and the access point to which it connects have a shared key. 

Standardization Efforts: WEP (Wired Equivalent Privacy) is specified in the IEEE 802.11 standard [158]. 
The protocol is intended to offer confidential and authenticated communication. The protocol is 
symmetric key based (it uses either 40 bit, 104 bit, or 232 bit keys) and employs RC4 for confidentiality 
and CRC32 for authentication. WPA (Wi-Fi Protected Access) is a successor of WEP. It employs the 
Temporal Key Integrity Protocol (TKIP) a stronger set of encryption and authentication algorithms; but 
TKIP has been deprecated by the IEEE. The WPA2 is the latest version of the protocol suite which is 
described in [159]. 

Limitations: Practical key-recovery attacks against the WEP protocols have been devised [51, 119,297] 
and the protocol is considered completely broken. The use of this protocol should be avoided. WEP 
has been deprecated by the IEEE. The TKIP protocol was intended as a temporary replacement for 
WPA, and is capable of running on legacy hardware. The protocol fixes some of the design problems 
in WEP, but some attacks against TKIP have been found [145,228,230,281, 296,299]. A recent attack, 
[254], based on prior analysis of RC4 [16] in TLS, breaks the basic WPA protocol, and thus users should 
move to WPA2 as a matter of urgency. 

Technical Details: The protocol WPA2 uses stronger primitives. It employs the Counter Cipher mode 
with Message Authentication Code Protocol (CCMP), an encryption scheme that uses AES in CCM 
mode (see [115][Section 4.3.3]) and offers both message confidentiality and message authentication. 
While some weaknesses in settings where WPA2 is used exist, no serious attacks are known against 
the protocol itself. 



General Description: The GSM, UMTS and LTE protocols are designed to secure communications 
between a mobile phone and the operators' base station. The goal being to provide confidentiality 
services for the user and authentication services for the mobile phone operator. The protocols also 
define what happens when a user "roams" to another service provider's network, by for example 
travelling to another country. In addition the protocols provide a limited form of anonymisation of the 
user, by preventing a passive eavesdropper from linking one communication with another from the 
same phone. 

Standardization Efforts: The Universal Mobile Telecommunication System (UMTS) and its latest 
version called Long-Term Evolution (LTE) are standards for wireless communication in mobile phones 
and data terminals. The standard is developed by the 3rd Generation Partnership Project (3GPP) and 
is now at version 10. The protocol is intended as a replacement for GSM. All technical specification 
documents referenced in this section are available at www.3gpp.org . 



4.1 WEP/WPA 



4.2 UMTS/LTE 
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Limitations: There are known minor weaknesses in the cryptographic components used in LTE, in 
particular Kasumi [49] and SNOW 3G [50,194], but these do not seem to translate into attacks against 
the secure channel that they implement. 

Technical Details: Very roughly, the protocol works in two phases, a key-establishment and 
authentication phase, and a data transmission phase. Unlike the TLS and IPSec protocols discussed 
earlier the key establishment and authentication are obtained via symmetric as opposed to public key 
techniques. 

UMTS/LTE replaces the one-way authentication protocol used in GSM (which authenticates the 
mobile but not the network) with a stronger protocol called Authentication and Key Agreement (AKA). 
This is a three party protocol that involves a mobile station (MS) a serving network (SN) and the home 
environment (HE). Upon a successful execution of the protocol MS and SN have confirmed that they 
communicate with valid partners and establish a shared key. An additional design goal for the protocol 
is to protect the identity of the mobile station: an eavesdropper should not be able to determine 
whether the same mobile station was involved in two different runs of the protocol. 

The key shared between MS and SN is used to implement a bi-directional secure channel between the 
two parties. Integrity and confidentiality are implemented (respectively) via algorithms UIA1 and UEA1 
(in UMTS) [1] and UIA2 and UEA2 (in LTE) [2]. The algorithms have the same structure; the difference 
is determined by the underlying primitive: the Kasumi block cipher [4] in UMTS and SNOW 3G stream 
cipher [3] in LTE. 

There are no provable security guarantees for the protocol. The few published analyses for the 
protocol are mainly concerned with the anonymity guarantees [23,197] and indicate that the protocol 
is susceptible to a number of attacks against mobile station confidentiality. Security of the channel 
established via UMTS/LTE had not been thoroughly analysed. 

4.3 Bluetooth 

General Description: Bluetooth is technology for exchanging data, securely, over short-distances 
between up to seven devices. It is often used to connect devices on a body (for example a mobile 
phone and a headset) or within a vehicle (for example a mobile phone and the vehicles audio system). 

Standardization Efforts: The protocol stack for Bluetooth was originally standardised as IEEE802.15.1 
standard, which is no longer maintained. The current development is over seen by the Bluetooth 
Special Interest Group. We discuss the cryptographic features of Bluetooth 2.1; the later versions (the 
latest is Bluetooth 4.0) are mainly concerned with improved bandwidth and power efficiency with 
little changes to the underlying cryptography. 

Limitations: See below for issues related to the pairing of devices. 

Technical Details: Operating takes place in two stages. In the "pairing" stage, two Bluetooth devices 
agree on a pair of keys, an initialisation key used for mutual authentication via a challenge response 
protocol based on HMAC-SHA-256; after authentication succeeds, the devices also agree on a link key 
for encrypting the traffic. Since Bluetooth 2.1 this stage is implemented with Elliptic Curve Diffie- 
Hellman (ECDH); depending on the capabilities of the devices involved, several mechanisms for 
providing protection against man-in-the-middle can be used. Data is encrypted in Bluetooth using 
streamcipher E0. Each packet is XORed with a keystream obtained by running the E0 algorithm on 
several inputs, one of which is the key link and another is a unique identifier. 

The main weakness of Bluetooth is the pairing phase. Although stronger than in Bluetooth 1.0-2.0, 
pairing is still open to Man-ln-The-Middle attacks for devices without user input/output capabilities 
or other out-of-band communication means, or in configurations where a predefined PIN is used. As 
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far as confidentiality of the communication goes, the few known theoretical attacks against E0 
[118,152] do not seem to impact confidentiality of messages. Message integrity protection is 
implemented with a cyclic redundancy code and is therefore minimal. 

4.4 ZigBee 

General Description: ZigBee is a radio communication standard which can be considered to operate 
mainly at lower power and ranges than Bluetooth. The key idea is to provide extended ranges by 
utilising mesh networks of ZigBee connected devices. 

Standardization Efforts: The ZigBee protocol suite is defined by the ZigBee Alliance 
http://www.zigbee.org/ . 

Limitations: There are no known issues with the Zigbee protocols, although we know of no formal 
analysis of the protocols. 

Technical Details: Bulk data encryption and authentication is based on the symmetric key mechanisms 
of IEEE 802.15.4 [160], and key management is implemented either by active key management with 
ZigBee-specific uses of ECDSA/ECDH or by predistribution of symmetric keys. 

The main confidentiality algorithms are AES in CTR mode, an AES based CBC-MAC algorithm outputting 
either a 32-bit, 64-bit or 128-bit MAC value, or for combined authenticated encryption the use of AES 
in CCM mode, or a variant of CCM mode called CCM*. TLS support is provided with two mandatory 
cipher suites 

TLS_PSK_WITH_AES_128_CCM_8andTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, 

these derive keying material either via symmetric preshared keys or via a elliptic curve Diffie-Hellman 
key exchange authenticated with ECDSA respectively. An optional suite of 



prepares the shared keying material via a finite field Diffie-Hellman exchange authenticated with RSA 
signatures. 



General Description: The EMV system defines a "platform" for enabling a chip card to be used in 
banking applications. Generally this platform is used to implement the chip-and-pin system deployed 
across much of the world. It is also used in some countries to provide online banking services via the 
use of a cheap chip-card reader. The EMV system is slated to be rolled out world-wide with the 
adoption in the United States in the next couple of years. 

Standardization Efforts: The chip-and-pin bank/credit card system follows a specification defined by 
EMVCo. Since this report is mainly focused on cryptographic aspects, we will restrict our discussion to 
the cryptographic components only; which are defined in "EMV Book 2" [111]. A new system is 
currently in the process of being standardised. 

Limitations: There are a number of systems security level issues observed by the Cambridge security 
group [11,12,62,106,232]. 

Technical Details: Much of the existing EMV specification dates from before the advent of provable 
security; thus many of the mechanisms would not be considered cryptographically suitable for a new 
system. For example, the RSA based digital signature is DS1 from the standard ISO 9796-2 [167]; in a 
message recovery mode. As already explained in [115][Section 4.8.4], this scheme suffers from a 



TLS DHE RSA WITH AES 128 CCM 8 



4.5 EMV 
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number of weaknesses, although none have been exploited to any significant effect in the EMV 
system. 

As a second example, the RSA encryption method (used to encrypt PIN blocks in some countries) is 
bespoke and offers no security guarantees. The only known analysis of this algorithm is in [289], which 
presents a Bleichenbacher-style attack against this specific usage. 

Another issue is that the card is allowed to use the same RSA private key for signing and encryption. 
This is exploited in [98] via another Bleichenbacher-style attack which converts the decryption oracle 
provided by the Bleichenbacher-style attack into a signing oracle; in turn, this can be used to forge 
EMV transaction certificates. It should be stated that none of the above attacks has been shown to be 
exploitable "in the wild". Rather, they highlight potential problems with the current algorithm choices. 

The symmetric key encryption schemes used in EMV are also slightly old fashioned. Two block ciphers 
are supported Triple DES and AES, with the underlying encryption method being CBC mode. The 
standard supports two MAC functions, AMAC for use with single DES and CMAC for use with AES. 

EMVCo is currently engaged in the process of renewing their cryptographic specifications to bring 
them up to date. There has been a lot of work on defining elliptic curve based schemes for use in EMV. 
Some work has been done on analysing the specific protocols and schemes being considered for use 
in the new specifications. For example [74] presents a detailed security analysis of the key agreement 
and secure channel protocol which is proposed to be used to secure the communication between the 
chip card and the merchants' terminal. 
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5 Application Areas 

In this section we focus on specific application areas; and discuss the application of existing protocols 
to these areas. In this year's report we focus on the area of Cloud Computing only; the idea being that 
additional areas will be covered in future reports. 

5.1 Cloud Computing 

The notion of cloud computing is essentially a catch all buzzword for a number of differing ways of 
working, which in the past would have been called a client-server or mainframe model of computing. 
The key differentiator between cloud computing and prior models is that the server, or mainframe, is 
now a set of many connected computers. With individual computers being made to look like multiple 
physical computers via the use of virtualization. 

The main reason for the take up of the model of cloud computing is the reduced cost of utilising cloud 
infrastructures. Large data centres can be centralised, thus reducing costs of real estate and power 
(indeed some data centres are located next to their own power plants). In addition the use of one 
central infrastructure used by multiple clients (a concept called multi-tenancy) enables the client to 
expand and contract their usage on a needs basis (notion of on demand scalability). 

In general cloud computing offers a relatively neutral effect on system security. On one hand the 
centralisation and management of the security infrastructure enables the cloud's customers to enjoy 
a greater level of security than they would have if they ran the system "in house". On the other hand, 
the aggregation of customers into one homogeneous infrastructure provides an attacker with a single 
high value target. However, outsourcing produces problems related to ensuring the privacy of any 
outsourced data; a subject which we will come back to below. 

5.1.1 Cloud Models 

However, despite these commonalities cloud computing is not a single problem instance from the 
point of view of security. There are basically a number of differing cloud business models 2 and 
applications; each of which pose their own security challenges. The three core areas are denoted laaS, 
PaaS, and SaaS; 

• Infrastructure as a Service (laaS): Here the provider provides a set of virtual machines and 
storage capability to the users. The most well-known of these installations is perhaps 
Amazon's Elastic Computing Cloud (EC2) and Microsoft's Azure. From the point of view of the 
user the cloud provider presents them with a physical machine running a specific operating 
system which they remote log into. However this physical machine could be shared between 
multiple clients via virtualization. 

• Platform as a Service (PaaS): The next layer up is where the infrastructure provider presents 
a complete platform to the client, for example a LAMP stack of web-server, database and PHP 
engine, or a web-front end equivalent. In general the user has no knowledge (or need for 
knowledge) of the underlying hardware. The platform provides development building blocks 
for the user, and not an end user application. Charging is usually done on a usage basis 
(transaction or storage volume). The client then uses this platform to build their own 
applications. Some providers (e.g. Google) automatically scales the users storage and 
computing requirements with the users needs. 



2 In this section the focus is beyond the cloud infrastructure and the deployment model; the perspective used 
cover also what we want to achieve using the cloud infrastructure. 
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• Software as a Service (SaaS): Here the provider provides a number of applications to the user 
on their cloud infrastructure. Generally these are a set of web applications, and clients do not 
need to install anything on the cloud infrastructure; clients connect to the service via a 
standard web browser. The software is usually accessed via a web front end, and users pay on 
a per-use or monthly basis (or have the inconvenience of adverts). Examples of SaaS include 
Saleforce's applications, Microsoft's 365-suite, Google's applications such as Calendar, Email 
etc, and some online games. 

Each of the above application areas creates its own security challenges, some of which are 
standard and do not deviate from normal computing operations. Others, however, produce 
unique security problems due to the nature of the use of remote clouds. See the ENISA report 
[112] for a full discussion. 

Things become more complicated as the above only provides one division of the cloud space into 
application areas. One can also divide the different types of cloud infrastructure into subsets 
depending on the interaction and ownership of the data centre itself. The usual division in this 
regard is: 

• Private Cloud: This is a cloud infrastructure which is devoted to a single organisation. 
However, it need not be hosted by the organisation, or even located on the organisations 
premises. Thus the cloud infrastructure could reside anywhere. 

• Public Cloud: A public cloud on the other hand is one whose capability is open for general use 
by anyone. This is probably the type of cloud most people are aware of, whether via Amazon 
EC2 or Microsoft Azure. 

• Community Cloud: This is a half-way between private and public cloud, where a community 
of users come together to provide a common cloud infrastructure for their communities use. 
Examples could include those in the area of health care where hospitals pool their needs with 
others. 

• Hybrid Cloud: Whereas community clouds bind end users together into a single infrastructure 
provider, a hybrid clouds binds different cloud infrastructures together. An example could be 
a corporate web site hosting, where the hosting is performed on a public cloud, but the 
security sensitive data processing is performed on the corporates private cloud. 

5.2 Cloud Computing Security 

A good overview of general security in the area of cloud computing is given in the survey article [233]. 
In this report we focus primarily on the cryptographic aspects of cloud security, but the reader is 
warned that this is only the tip of the iceberg. However, the fact that cloud providers (in any model) 
are merging user requirements into one infrastructure can enable dedicated security expertise to be 
applied to a wider range of end user applications. Thus the scale issue of cloud computing can provide 
a potential security benefit as well as realising potential security problems, see the ENISA reports 
[112,114]. 

In many cloud application areas basic cryptographic security mechanisms can be deployed to ensure 
operations are performed securely. For example in the laaS model one should log into the remote 
service using SSH, when interacting with services in any model one should utilise connections over 
TLS/SSL, passwords should be strong, etc. Since at its heart cloud computing is nothing but a variant 
on the client-server model of computing, with some extra web front ends added for various 
applications, standard security as for any client-server or web application can be provided by basic 
cryptographic protocols. 
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The key aspect of cloud computing is the use of virtualized machines, where various users (called 
tenants) access the same physical hardware. This allows various so-called cross VM-attacks; where 
attackers who are co-resident on the same physical hardware extract data from one VM via the effects 
of aspects of the same hardware being used (usually cache based side-channels). Of course to mount 
such attacks an adversary needs to be co-resident on the same physical machine as the intended 
victim. See [272,317] for a discussion of such attacks in the cloud environment. 

The use-case of cloud computing brings up its own set of problems. These are mainly due to the utility 
computing nature of the resource: Services are provided by third parties and not in house, and users 
have no real guarantee that the service provider is doing what they claim to be doing. In the next 
paragraphs will detail some of these issues. The cryptographic solutions to solve these issues are 
somewhat in their infancy, or not deployed to large extent. 

Guarantee of Image: In the laaS model a user selects a given image to install on the virtual machine. 
For example this could be a specified version of Ubunto Linux with certain packages already installed. 
This image is then loaded and the user can access the virtual machine as if it were a stand-alone 
machine. The problem is that the user has almost no guarantee that the provider has loaded the 
desired image on, and with no modifications. In addition the entire software stack up to and including 
the image needs to be trusted; this includes the hypervisor which is used to share resources between 
the different virtual machines on the same physical hardware. 

Technologies exist which can address this issue, for example Direct Anonymous Attestation (DAA) 
allows one machine to attest to its configuration state to another [46, 72]. This is done by utilising 
zero-knowledge protocols and some special functionality designed into the TPM chip which sits on 
most computer motherboards. However, take up of this technology has been limited. 

Proofs of Data Storage: If a cloud infrastructure is used for long term storage, say for example many 
years, then a client may want to know whether the data they uploaded is still there. After all a rogue 
provider could still charge for storage which they have deleted on the hope that the client never asks 
for the data back. However, the data may be so large that the client simply asking for it to be 
downloaded every so often for checking may not be feasible. This leads to the topic of Proofs of 
Storage. These are cryptographic protocols which enable a storage provider to prove to a client that 
certain files are still being stored, without the client needing to keep copies of all that has been stored. 

Juels and Kaliski address the problem of how to provide data owners with formal assurance that their 
data still exists (and that it can be recovered in full) by introducing Proofs of Retrievability (POR) [179]. 
Juels and Kaliski's POR system works by first encoding a file F under some key K. The user retains the 
key K and the encoded file F' is stored at the server. To obtain a POR a user can query the server storing 
the file with a series of challenges and verify the server's responses using the key K. A similar type of 
protocol known as Proofs of Data Possession was proposed by Ateniese et al. [24]. 

Further research in this area has resulted in more efficient schemes such as the "Compact Proofs of 
Retrievability" by Shacham and Waters [282]. The most recent development has been in the area is 
Dynamic PORs [83,285]. In traditional POR schemes data is static and cannot be updated. Dynamic 
POR schemes provide assurance about data Retrievability whilst still allowing the data owner to 
perform arbitrary changes to data. 

Proofs of Data Location: For many types of sensitive data, e.g. health records, it is extremely important 
that it remains within the appropriate legal jurisdiction. For example, Canadian law requires that 
health care data and other sensitive personal information is restricted to machines which are 
physically located in Canada. As a result, when outsourcing data to the cloud data owners may request 
that their data only be stored within a specific geographic location. Watson et al. [305] provide a 
construction for such a scheme under the assumption that data centres must declare all copies of files 
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to their owners. Their construction is based on Proofs of Retrievability [282] and Time-Based 
Geolocation schemes [186]. Similar work has been carried out by Albeshri et al. [14]. 

5.3 Data Security in the Cloud: Future Technology 

The main perceived security problem with cloud computing is that data loaded into the cloud is no 
longer in the control of the data creator, or the data controller in the case of data collected by an 
organisation and then passed to the cloud. In many cloud applications the reason for moving to the 
cloud is to enable computation on the said data using fast and cheap cloud infrastructure. 

There is a conflict between the need to secure data and the need to process it. Simply encrypting the 
data and then passing it to the cloud for storage, solves only half the problem. When the data has to 
be retrieved, processed or searched, use of standard encryption is not useful. One either has to allow 
the cloud to decrypt the data, or to download the entire data set to the user's machine, thereby 
mitigating the benefits of moving to the cloud in the first place. 

The article [182] provides a good overview of the cryptographic mechanisms which can support cloud 
applications focused on securing data storage (as opposed to data processing). But even if processing 
is not required, one needs some additional cryptographic functionality to be able to search and 
retrieve data which has been stored in the cloud. 

There are a number of emerging technologies which aim to solve this clash of requirements. We 
outline just a few of either the most well-known, or the most promising. 

• Fully Homomorphic Encryption (FHE) 

• Multi-Party Computation (MPC) 

• Searchable Encryption 

• Order Preserving Encryption 

• Attribute Based Encryption 

• Delegated Computation 

We now deal with each of these technologies in turn. Most are experimental technologies in that they 
are not mature enough yet for deployment, or they are only suitable for a relatively limited number 
of applications. 

Fully Homomorphic Encryption (FHE): Probably the biggest encryption advance to attract widespread 
attention in the last few years has been the invention of Fully Homomorphic Encryption (FHE) by 
Gentry in [127,128]. The basic idea is that an arithmetic circuit can be applied to a set of ciphertexts, 
the result being the encryption of the output of the arithmetic circuit as if it had been evaluated on 
the underlying plaintexts. Since all FHE schemes are semantically secure, the ciphertext reveals no 
information about the plaintext (without possession of the decryption key). FHE schemes allow 
computations of arbitrary functions on the underlying plaintexts. In general an FHE scheme can 
evaluate any circuit, whereas a Somewhat Homomorphic Encryption (SHE) scheme can evaluate only 
circuits of bounded (multiplicative) depth, namely functions of bounded size. 

In the cloud scenario the use case for FHE would be for the data owner to encrypt their data D, to 
obtain enc(D) and send it to the cloud provider. Then suppose the data owner wanted to perform 
some operation/on the data D to obtain/fDj. For example D could be a data base and/could be a 
search for all items corresponding to the person "John Doe". With FHE/SHE the cloud infrastructure 
can compute enc(f(D)), which is then returned to the data owner. The data owner then decrypts this 
ciphertext to obtain f(D). 

The construction of SHE schemes is now at a point where relatively simple circuits can be evaluated 
efficiently. There are a number of such schemes, of which the most efficient are those based on Ring- 
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LWE. For example the BGV scheme [66, 67] and the NTRU based scheme [64,217]. All the ring based 
SHE schemes support the concept of SIMD evaluation [66, 130, 290], which enables more efficient 
processing of bulk data. The other family of efficient schemes are those based on integer approximate- 
GCD problems [300]; this scheme has been extended to cope with SIMD processing in [85]. 

To turn an SHE scheme into an FHE scheme one needs a technique to bootstrap. The current state of 
the art in bootstrapping is far from what could be deemed truly practical. But at the time of writing 
the following are the key best-in-class results [18, 19, 85, 129, 243]. The standard benchmark for 
evaluating SHE/FHE schemes is to present run times for evaluating the AES functionality in a secure 
manner, see [85,131]. 

Multi-Party Computation (MPC): Multi-Party Computation (MPC) allows the equivalent of FHE, but 
with the use of multiple servers as opposed to a single one. Thus data can (theoretically) be securely 
outsourced to multiple cloud providers who then can compute on this data, such that one can tolerate 
a set of colluding adversaries (up to some bound on the number of adversaries). 

The cloud scenario where this could be applied would be as follows. A data owner 'splits' their data D 
into shares Dl, ... , Dn via a secret sharing scheme. The shares are then distributed to n distinct cloud 
providers. The cloud providers are now able to compute any function f(D), but they obtain an answer 
which is shared. The shares are then returned to the data owner for combining into the final solution 
f(D). The key security concept being that as long as the data owner trusts n - t out of the n servers, 
their data is still kept confidentially. Here t is the maximum number of adversaries which can be 
tolerated. 

The concept of MPC has been around for a longtime, with much of the foundational work dating back 
to the 1980's [31, 43, 84, 310, 311]. Security is usually defined to be one of passive or active security. 
In a passively secure protocol the adversaries are assumed to follow the protocol, and the protocol 
protects against privacy violations. In an actively secure protocol the adversaries can arbitrarily 
deviate from the protocol and privacy (and in some cases accuracy) is still preserved. 

There are two families of MPC protocols; one for an arbitrary number of players based on secret 
sharing (which originate in [43, 84]); whilst the other are based on the concept of garbled circuits 
(which originate in [31,310,311]) and are focused on two parties. 

In recent years there have been major advances in the capability of MPC systems. Some passively 
secure systems have been deployed to solve real world problems, e.g. [57, 58]. Indeed, at least three 
small companies Dyadic Security (Israel), Partisia (Denmark) and Cybernetica (Estonia) have products 
based on MPC. In addition SAP (Germany) has had a long standing research programme on using MPC 
for supply chain management decisions. 

In terms of actively secure secret sharing based protocols, recent years have seen staggering efficiency 
gains in this area, see for example [45, 95, 97, 238]. We can now compute relatively complex functions 
f via MPC techniques, this has resulted in the interest of companies mentioned above. The protocol in 
[97] is notable as it uses SHE as a way of enhancing performance; which demonstrates that SHE can 
be used for some practical purposes already. A similar improvement has been witnessed in practical 
results for garbled circuit based constructions, see for example [68,156, 212-214,229] for protocol 
improvements and [122,200,262,283] for implementation improvements. 

Searchable Encryption: Searchable Encryption aims to solve the following problem. A user outsources 
a database to a server, and then wants to query the server to obtain data. The first key question is 
what do we mean by security in this context? Clearly the database contents should remain private to 
the client, but should the access patterns also be private? The answer to this question is a design 
decision for an application developer, but it has an impact on the precise cryptographic solution one 
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is after. To obtain privacy of the access patterns a more complex cryptographic solution is required, 
which we will come to below after we have discussed the basic scenario. 

Searchable encryption comes in two variants; a public key and a symmetric key variant. In both 
variants the encrypted database is augmented with a set of tokens. Each token is associated with a 
keyword. The database itself is encrypted with any encryption algorithm, the searchable encryption 
scheme is solely used to perform the construction, and searching, of the tokens. Thus searchable 
encryption schemes are focused purely on searching for keywords. 

The public key variants (called PEKS in the literature) are probably less useful in the cloud scenario 
(due to the presence of a selected keyword attack). But see [7, 63] for more details on public key 
variants. 

Symmetric Searchable Encryption (SSE) on the other hand has seen great advances in the last few 
years. With improvements in both the security model and in terms of efficient constructions, see 
[82,92,135,183,291,301]. The paper [82] presents examples of encrypted search on a databases with 
over 13 million documents, equivalent to 0.4 Terrabytes of data. 

To obtain privacy of the access patterns the SSE scheme needs to be augmented with something akin 
to Oblivious RAM (ORAM), a concept introduced by Goldreich and Ostrovsky in 1996 [139]. Recent 
years has seen a great advance in protocols to implement ORAM, most notably by Elaine Shi and her 
co-authors. See for example [96,140,141,202,216,245,247,261,284,294,295,306-308]. 

Order Preserving Encryption (OPE): Order Preserving Encryption (OPE) solves a variant of the 
searchable encryption problem in another way. It enables ciphertexts to be ordered in a way which 
respects the ordering of the underlying plaintexts. Thus binary search can be conducted on the 
ciphertexts. OPE had been originally introduced in a naive way in the database community [13]. A 
more scientific treatment is presented in [59, 60]. The key problem with OPE is that the security 
definitions are incredibly weak. It has however been used in systems such as CryptDB, see below. 

Attribute Based Encryption (ABE): Attribute Based Encryption (ABE) is an extension of Identity Based 
Encryption where by decryption of data is allowed on the basis of whether the decryptor satisfies a 
set of policies associated with given secret keys, which are themselves associated to attributes. The 
key concept applicable to cloud scenarios is that complex access control policies for encrypted 
outsourced data can be embedded within the ciphertext itself. This means that a data owner does not 
need to trust the cloud provider to implement a policy they require. 

The idea was first formally introduced by Sahai and Waters in [278], but the basic idea of using IBE to 
perform policy based decryption goes back a bit further, e.g. to [288]. Since its invention the literature 
on ABE has been enormous, with a significant body of work being attributed to Lewko, Sahai, and 
Waters, see for example [47,142,209-211,246,263] amongst many other papers. 

ABE comes in two variants so called Ciphertext Policy and Key Policy ABE schemes, or CP- ABE and KP- 
ABE schemes. In CP-ABE schemes the encryptor has the list of attributes and he creates a ciphertext 
which can be decrypted under a policy based on these attributes. In KP-ABE schemes the policies are 
associated to the keys, as opposed to the ciphertexts. The decryptor can decrypt if he has a key whose 
underlying policy is satisfied by the given attributes. 

Delegated Computation: A whole sub-area of delegated computation has arisen; mainly consisting of 
theoretical proof-of-concept results. The key aspects of delegated computation are the following 

• A resource constrained client can delegate a computation to a powerful cloud service 
provider 

• The client can check whether the provider has performed the correct computation. 
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Delegated computation can run in either a non-private manner (in which the cloud server learns the 
clients data), or a private manner (in which case the input data, and perhaps the function, are kept 
private). As remarked, almost all of the work on cryptographically secure delegated computation is of 
a theoretical nature at present. The key literature on this problem can be found in [80, 86, 125, 126, 
249]; all of which utilise ideas from FHE, MPC and ABE in some way. A notable exception to the 
theoretical work is the Pinochio system of Parno et al [248] which presents a semi-practical system for 
verification of non-private delegated computation. 

De-Duplication: Another issue which arises in secure storage on the cloud is one of secure de- 
duplication. Services such as Dropbox enable a user to store large amounts of data. However, to keep 
the costs down a cloud provider does not store multiple copies of the same file. This is important for 
cloud based back-up services; since many files which need to be backed up are common across many 
users. Thus, assuming files are not encrypted, de-duplication enables cloud providers to provide such 
services at a lower cost. 

However, as soon as a user wants to encrypt their data the cloud provider is unable to perform de- 
duplication. This is because all secure encryption algorithms are probabilistic in nature. This has led to 
the introduction of encryption algorithms which are deterministic and data dependent, called 
message locked encryption [5,35]. The basic idea in this line of work is to encrypt the data under a 
symmetric key which is obtained as a function of the message. Thus identical messages will lead to 
identical ciphertexts, and the data owner needs only store the key (which is short) along with its file 
handle so as to be able to retrieve it (via the handle) and then decrypt it (via the key). 

Summary: We summarise the above technologies in Table 6.1 to indicate whether they are ready for 
application in limited environments and application domains, whether more research is needed but 
they should be ready in the short to medium term for major deployment (and maybe limited 
deployment in the meantime) or whether they require a great deal more research before they are 
ready for practical deployment. Note, a technology can have multiple ticks to it on this classification. 



Technology 


Ready for 


Short Term 


Longer Term 




Deployment 


Research Needed 


Research Needed 


Fully Homomorphic Encryption 


X 


X 


V 


Multi-Party Computation 


V 


V 


X 


Searchable Encryption 


V 


V 


X 


Order Preserving Encryption 


X 


X 


V 


Attribute Based Encryption 


X 


V 


X 


Delegated Computation 


X 


X 


V 


Message Locked Encryption 


V 


V 


X 



Table 5.1: Summary of technology readiness of advanced cryptographic mechanisms 



5.3.1. CryptDB 

In [264] Popa et al present a realisation of a database which can be queried using a restricted set of 
SQL queries, but for which the database entries are encrypted. The resulting system, called CryptDB, 
is relatively efficient and enables a large enough set of standard SQL queries to be executed with a 
reasonable delay compared to computing with an unencrypted database. The scenario is that a data 
holder is aimingto outsource their database to a third party cloud provider; whilst wantingto maintain 
database security as well as maintain a reasonable amount of standard SQL functionality. 

The basic idea behind CryptDB is to take a sensitive column in the database and then to encrypt it 
using successively stronger forms of encryption; such as standard encryption, SSE and OPE. The system 
is efficient, but suffers from inherent leakage of information. This means that CryptDB essentially only 



Page 25 



* * Study on cryptographic protocols 

^ ^* November, 2014 

provides a layer of weak security to an outsourced database application, as opposed to providing truly 
strong security. 

A similar idea to CryptDB is the SEEED system of SAP [143], which extends the SQL syntax of CryptDB 
to support more elaborate queries. 
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